1. Field of the Invention
2. Related Art
IBM System 390 Architecture is classified as a Complex Instruction Set Computing (CISC) architecture. The instruction sets from CISC architectures include both simple instructions (e.g. Load, or Add) and complex instructions (e.g. Program Call, or Load Address Space Parameters). As these computer systems have become more powerful, larger percentages of the instruction set have been implemented using hardware execution units to increase the systems performance. Conventionally, the complex functions are implemented in microcode because building hardware execution units to execute them is expensive and error prone.
Implementing complex functions in microcode provides flexibility to fix problems and expandability in that additional functions can be included later. In machines where much of the processor is hardware controlled, a dedicated microprocessor based execution unit is often provided in order to implement the complex functions. This unit can be microprogrammed to execute complex instructions and complex functions such as handling interrupt conditions. While most of these functions occur relatively rarely, they can execute for tens or hundreds of cycles.
Although the above-described configuration provides flexibility, including a microprocessor execution unit in a computer system with many hardware execution units causes some problems Typically, the path from a microprocessor's control store to the microprocessor itself is critical in that it can effect the system cycle time. This is, in part, because of the need to support multiway branching. In a machine that contains many hardware controlled execution units, there are many other cycle time determining paths. Since much of the processor function is accomplished in hardware execution units, it is desirable to place the microprocessor physically near the hardware execution units so that the microprocessor can have quick access to the results that the hardware execution units generate. Adding a microprocessor execution unit, with its set of critical paths, near the other hardware execution units means adding critical paths in an area that already has many other critical paths.
The complex functions can consume many cycles for their execution. When this happens in a design where the microprocessor is executing the long running function, the remaining hardware execution units may become idle as they wait for the results from the long running function. This is an inefficient use of the available execution units. It is desirable to execute these complex functions as quickly as possible. Further, microprocessor implementation of complex functions requires access to the architected facilities that are being manipulated by the hardware execution units. This implies the need for an increasingly complex interface between the microprocessor and the hardware execution units. The problem is how to provide the flexibility of a microprocessor while not including one in the design.
One solution is suggested in an IBM Technical Disclosure Bulletin article entitled "COMBINED MACRO/MICRO PROGRAM MACHINE" (IBM TDB Vol. 14, No. 1, June 1971, pg.298). To raise the speed of a microprogram controlled computer without essentially increasing the hardware, the same instruction format is adopted for both macro and micro-instructions. This permits designing the hardware so that simple macro-instructions i.e. for simple functions, such as "LOAD REGISTER", "STORE REGISTER INTO MAIN STORAGE", etc., can be directly implemented. More complex macro-instructions involving, for example, floating point and decimal arithmetics are interpreted by micro-instructions which are also directly implementable, using the same hardware. The micro-instructions employed to interpret more complex macro-instructions are also directly used (as simple macro-instructions) in the user program.
Thus, in the above-described system, the user program consists of a sequence of simple micro-instructions and complex macro-instructions. When instructions are implemented, it is determined by testing the operation code whether a current instruction is one that can be directly implemented or is an instruction to be interpreted. This test results in a mode switch being set to either the micro or macro mode. For complex macro-instructions, a branch is taken to an interpretation unit which is a normal microprogram control with control store and instruction sequencer.
Since both the micro-instructions and the simple macro-instructions have the same format, all macro-instructions can be implemented by the instruction execution hardware. Thus, the more complex macro-instructions (as interpreted into micro-instructions by the interpretation unit), as well as the simple macro-instructions (directly appearing in the user program) are transferred to the instruction execution unit.
While the above-described system provides increased flexibility and processing speed, it leaves a number of problems unsolved One problem relates to the manipulation of facilities that are normally not accessible to the architected instruction set. In many instances, it may be necessary or desirable for microcode to have an exclusive ability to manipulate such facilities. In the above described system, there is no provision for giving special access to the micro-instructions coming from the interpretation unit.
Other problems left unsolved by the above-described system include the application of the technique to a parallel and/or pipelined environment, tracking of interpretive instructions as they make their way through the instruction pipeline, managing the micro and macro-instruction registers, and the transfer of operands between the interpretive routines and the macro-instructions that the routines are intended to implement.